Mitigating denial of service attacks on call centers

ABSTRACT

A device receives, from a user device, a call destined for a call center, and provides an audio CAPTCHA (Completely Automated Public Turing test to Tell Computer and Humans Apart) to the user device in response to the call. The device also receives, from the user device, a response to the audio CAPTCHA, and determines whether the response is correct. The device forwards the call to the call center when the response is correct, and drops the call when the response is incorrect.

BACKGROUND

Network attacks may include denial of service (DoS) attacks, port scansand network probes to detect and exploit system vulnerabilities,protocol-based attacks on intermediary routing systems, etc. DoS attacksmay include overwhelming of a service with traffic in an attempt toprevent legitimate users from using the service. As service providersdevelop value added revenue sources based on Internet protocol (IP)application services, such as voice-over-IP (VoIP), the open nature ofthe IP infrastructure may put those revenue sources at risk. Excessivetraffic and resource depletion attacks may use either forged or spoofedsource addresses or compromised hosts (e.g., VoIP soft clients, botnets,etc.). These mechanisms increase the difficulty in tracing an attackback to the initiator of the attack. Routing protocol-based attacks canbe used to compromise legitimate routing and forwarding.

In one example, DoS attacks maliciously target inbound services (e.g.,8XX services, direct dial services, etc.) to disrupt an enterprise callcenter. VoIP soft clients and/or botnets are scripted for mass callingof a call center, and an originating number is uniquely spoofed for eachcall. The call volume generated by the mass calling fills network trunksand prevents call center agents from providing service to real clients.Conversions between VoIP networks and the public switched telephonenetwork (PSTN) removes details associated with the calls, which may behelpful for remediation. However, many VoIP carriers that are thesources of such mass calls refuse to investigate or address originatorsof the mass calls. Without the assistance of the VoIP carriers, it maybe almost impossible for call center providers to prevent disruptive DoSattacks on call centers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example network in which systems and/ormethods described herein may be implemented;

FIG. 2 is a diagram of example components of a device that maycorrespond to one of the devices of the network depicted in FIG. 1;

FIG. 3 is a diagram of example operations capable of being performed byan example portion of the network in FIG. 1;

FIG. 4 is a diagram of example operations capable of being performed byanother example portion of the network in FIG. 1;

FIG. 5 is a diagram of example functional components of an audio CAPTCHA(Completely Automated Public Turing test to Tell Computer and HumansApart) component of a session border control (SBC) device depicted inFIGS. 1, 3, and 4; and

FIGS. 6 and 7 are flow charts of an example process for mitigatingdenial of service attacks on call centers according to an implementationdescribed herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

Systems and/or methods described herein may provide a mechanism toprevent DoS attacks on call centers when call volumes at the callcenters reach a particular threshold level. In one example, themechanism may include an audio CAPTCHA (Completely Automated PublicTuring test to Tell Computer and Humans Apart) that prevents automatedDoS calls from reaching call centers. The audio CAPTCHA may provide anaudio request to a user of a user device placing a call to a callcenter, and the user may provide an audio response to the audio request.If the user provides an audio response that satisfies the audio request,the call may be forwarded to the call center. However, if the audioresponse does not satisfy the audio request, the call may be dropped inorder to prevent DoS attacks on the call center. The complexity of theaudio CAPTCHA may be carefully balanced so as to have a high pass ratefor humans (e.g., users of user devices) and a low pass rate for devices(e.g., computers).

As used herein, the terms “user” and “customer” are intended to bebroadly interpreted to include a user device or a user of a user device.

The term “component,” as used herein, is intended to be broadlyconstrued to include hardware (e.g., a processor, a microprocessor, anapplication-specific integrated circuit (ASIC), a field-programmablegate array (FPGA), a chip, a memory device (e.g., a read only memory(ROM), a random access memory (RAM), etc.), etc.) or a combination ofhardware and software (e.g., a processor, microprocessor, ASIC, etc.executing software contained in a memory device).

FIG. 1 is a diagram of an example network 100 in which systems and/ormethods described herein may be implemented. As illustrated, network 100may include user devices 110, a VoIP network 120, a PSTN 130, a network140, a time-division multiplexing (TDM)-based call center 150, and aVoIP-based call center 160. Network 140 may include a tandem switch (TS)142, an end office switch (EOS) 144, a media gateway (MGW) 146, and asession border controller (SBC) 148. Devices and/or networks of network100 may interconnect via wired and/or wireless connections. Two userdevices 110, one VoIP network 120, one PSTN 130, one network 140, one TS142, one EOS 144, one MGW 146, one SBC 148, one TDM-based call center150, and one VoIP-based call center 160 have been illustrated in FIG. 1for simplicity. In practice, there may be more user devices 110, VoIPnetworks 120, PSTNs 130, networks 140, TSs 142, EOSs 144, MGWs 146, SBCs148, TDM-based call centers 150, and/or VoIP-based call centers 160.

User device 110 may include a radiotelephone; a personal communicationssystem (PCS) terminal, that may, for example, combine a cellularradiotelephone with data processing and data communicationscapabilities; a wireless telephone; a cellular telephone; a smart phone;a personal digital assistant (PDA) that can include, for example, aradiotelephone, a pager, Interet/intranet access, etc.; a laptopcomputer; a tablet computer; a desktop computer; a workstation computer;a server device; or other types of computation and communicationdevices. In one example, user device 110 may include a device that iscapable of communicating with TDM-based call center 150 and/orVoIP-based call center 160 over VoIP network 120, PSTN 130, and/ornetwork 140.

VoIP network 120 may include an IP-based network, a packet-switchednetwork, or a combination of networks that enable the delivery of voicecommunications and multimedia sessions. In one example, VoIP network 120may enable VoIP telephone calls from user devices 110 to be provided toVoIP-based call center 160. In order to originate a VoIP telephone call,user device 110 may set up a signaling/media channel, may digitize theanalog voice signal, may encode the digitized voice signal, maypacketize the digitized voice signal, and may transmit the packet overVoIP network 120.

PSTN 130 may include a network of public circuit-switched telephonenetworks. PSTN 130 may include telephone lines, fiber optic cables,microwave transmission links, cellular networks, communicationsatellites, telephone cables, etc. interconnected by switching centers,and may allow a telephone to communicate with any other telephone. Inone example, PSTN 130 may enable TDM-based telephone calls from userdevices 110 to be provided to TDM-based call center 150.

Network 140 may include a local area network (LAN), a wide area network(WAN), a metropolitan area network (MAN), a telephone network, anintranet, the Internet, an optical fiber (or fiber optic)-based network,or a combination of networks.

TS 142 may include one or more traffic transfer devices (or networkdevices), such as a gateway, a router, a switch, a firewall, a networkinterface card (NIC), a hub, a bridge, a proxy server, an opticaladd-drop multiplexer (OADM), or some other type of device that processesand/or transfers traffic. In one example implementation, TS 142 mayinclude a device that is specialized for TDM-based, circuit-switchedtelephone calls. TS 142 may connect a TDM-based call from user device110 to TDM-based call center 150, via EOS 144. TS 142 may connect aVoIP-based call from user device 110 to VoIP-based call center 160, viaMGW 146 and SBC 148.

EOS 144 may include one or more traffic transfer devices (or networkdevices), such as a gateway, a router, a switch, a firewall, a NIC, ahub, a bridge, a proxy server, an OADM, or some other type of devicethat processes and/or transfers traffic. In one example implementation,EOS 144 may include a device that is specialized for TDM-based,circuit-switched telephone calls. EOS 144 may connect a TDM-based callfrom user device 110 to TDM-based call center 150.

MGW 146 may include one or more traffic transfer devices (or networkdevices), such as a gateway, a router, a switch, a firewall, a NIC, ahub, a bridge, a proxy server, an OADM, or some other type of devicethat processes and/or transfers traffic. In one example implementation,MGW 146 may include a translation device that converts digital mediastreams between disparate telecommunications networks such as PSTN 130,a signaling system 7 (SS7) network, etc.

SBC 148 may include one or more computation and communication devicesthat gather, process, search, and/or provide information in a mannerdescribed herein. In one example, SBC 148 may provide control oversignaling and media streams involved in setting up, conducting, andtearing down telephone calls or other interactive media communications.In one example implementation, SBC 148 may receive, from user device110, a call destined for TDM-based call center 150 or VoIP-based callcenter 160, and may provide an audio CAPTCHA to user device 110. Theaudio CAPTCHA may provide an audio request to a user of user device 110,and the user may provide an audio response to the audio request. If theuser provides an audio response that satisfies the audio request, thecall may be forwarded to TDM-based call center 150 or VoIP-based callcenter 160. However, if the audio response does not satisfy the audiorequest, the call may be dropped in order to prevent DoS attacks onTDM-based call center 150 or VoIP-based call center 160.

Alternatively, SBC 148 may receive call volume information associatedwith TDM-based call center 150 or VoIP-based call center 160, and maydetermine whether the call is eligible for the audio CAPTCHA based onthe call volume information. For example, if the call volume informationindicates that the call volume at TDM-based call center 150 orVoIP-based call center 160 is greater than a particular threshold (e.g.,60%, 70%, 80%, etc. of the capacity of call centers 150/160), SBC 148may determine that the call is eligible for the audio CAPTCHA. If SBC148 determines that the call is not eligible for the audio CAPTCHA, SBC148 may forward the call to TDM-based call center 150 or VoIP-based callcenter 160.

TDM-based call center 150 may include one or more computation andcommunication devices that handle TDM-based or other non-VoIP customerservice calls from user devices 110. In one example, TDM-based callcenter 150 may be operated by a service provider in order to provideproduct and/or service support or to answer information inquiries fromcustomers. In one example, customer service representatives at TDM-basedcall center 150 may receive customer service calls, and may address therequests associated with the customer service calls.

VoIP-based call center 160 may include one or more computation andcommunication devices that handle VoIP-based customer service calls fromuser devices 110. In one example, VoIP-based call center 160 may beoperated by a service provider in order to provide product and/orservice support or to answer information inquiries from customers. Inone example, customer service representatives at VoIP-based call center160 may receive customer service calls, and may address the requestsassociated with the customer service calls.

Although FIG. 1 shows example devices/networks of network 100, in otherimplementations, network 100 may include fewer devices/networks,different devices/networks, differently arranged devices/networks, oradditional devices/networks than depicted in FIG. 1. Alternatively, oradditionally, one or more devices/networks of network 100 may performone or more tasks described as being performed by one or more otherdevices/networks of network 100.

FIG. 2 is a diagram of example components of a device 200 that maycorrespond to one of the devices of network 100. In one exampleimplementation, one or more of the devices of network 100 may includeone or more devices 200. As illustrated in FIG. 2, device 200 mayinclude a bus 210, a processing unit 220, a memory 230, an input device240, an output device 250, and a communication interface 260.

Bus 210 may permit communication among the components of device 200.Processing unit 220 may include one or more processors ormicroprocessors that interpret and execute instructions. In otherimplementations, processing unit 220 may be implemented as or includeone or more ASICs, FPGAs, or the like.

Memory 230 may include a RAM or another type of dynamic storage devicethat stores information and instructions for execution by processingunit 220, a ROM or another type of static storage device that storesstatic information and instructions for the processing unit 220, and/orsome other type of magnetic or optical recording medium and itscorresponding drive for storing information and/or instructions.

Input device 240 may include a device that permits an operator to inputinformation to device 200, such as a keyboard, a keypad, a mouse, a pen,a microphone, one or more biometric mechanisms, and the like. Outputdevice 250 may include a device that outputs information to theoperator, such as a display, a speaker, etc.

Communication interface 260 may include any transceiver-like mechanismthat enables device 200 to communicate with other devices and/orsystems. For example, communication interface 260 may include mechanismsfor communicating with other devices, such as other devices of network100.

As described herein, device 200 may perform certain operations inresponse to processing unit 220 executing software instructionscontained in a computer-readable medium, such as memory 230. Acomputer-readable medium may be defined as a non-transitory memorydevice. A memory device may include space within a single physicalmemory device or spread across multiple physical memory devices. Thesoftware instructions may be read into memory 230 from anothercomputer-readable medium or from another device via communicationinterface 260. The software instructions contained in memory 230 maycause processing unit 220 to perform processes described herein.Alternatively, or additionally, hardwired circuitry may be used in placeof or in combination with software instructions to implement processesdescribed herein. Thus, implementations described herein are not limitedto any specific combination of hardware circuitry and software.

Although FIG. 2 shows example components of device 200, in otherimplementations, device 200 may include fewer components, differentcomponents, differently arranged components, or additional componentsthan depicted in FIG. 2. Alternatively, or additionally, one or morecomponents of device 200 may perform one or more tasks described asbeing performed by one or more other components of device 200.

FIG. 3 is a diagram of example operations capable of being performed byan example portion 300 of network 100 (FIG. 1). As shown in FIG. 3,network portion 300 may include user device 110, TS 142, MGW 146, SBC148, and VoIP-based call center 160. User device 110, TS 142, MGW 146,SBC 148, and VoIP-based call center 160 may include the featuresdescribed above in connection with, for example, one or more of FIGS. 1and 2. As further shown in FIG. 3, SBC 148 may include an audio CAPTCHAcomponent 310.

A user of user device 110 may generate a VoIP call 320, and user device110 may provide VoIP call 320 to TS 142. In one example, VoIP call 320may include a voice call destined for VoIP-based call center 160. TS 142may receive VoIP call 320, and may provide VoIP call 320 to MGW 146. MGW146 may receive VoIP call 320, and may provide VoIP call 320 to audioCAPTCHA component 310 of SBC 148.

Audio CAPTCHA component 310 may receive VoIP call 320 and may receivecall volume information 330. Call volume information 330 may includeinformation indicating a volume or a number of calls currently beingreceived by VoIP-based call center 160. In one example implementation,audio CAPTCHA component 310 may verify that a human is generating VoIPcall 320 by generating an audio CAPTCHA 340 in response to VoIP call320. Audio CAPTCHA 340 may include randomized letters, numbers, phrases,etc. that are mixed with noise and/or background voices to prevent voicerecognition by devices, such as computers. Similar to visual CAPTCHAsthat are used to thwart automated posting or data harvesting on theInternet, audio CAPTCHA 340 may provide an automated approach tomitigating DoS attacks on VoIP-based call center 160. In one exampleaudio CAPTCHA 340 may have a high pass rate for humans and a low passrate for devices, such as computers.

Alternatively, audio CAPTCHA component 310 may determine whether VoIPcall 320 is eligible for audio CAPTCHA 340 based on call volumeinformation 330. If call volume information 330 indicates that the callvolume at VoIP-based call center 160 is greater than a particularthreshold (e.g., 60%, 70%, 80%, etc. of the capacity of VoIP-based callcenter 160), audio CAPTCHA component 310 may determine that VoIP call320 is eligible for audio CAPTCHA 340. If audio CAPTCHA component 310determines that VoIP call 320 is not eligible for audio CAPTCHA 340,audio CAPTCHA component 310 may forward VoIP call 320 to VoIP-based callcenter 160, as indicated by reference number 360.

As further shown in FIG. 3, audio CAPTCHA component 310 may provideaudio CAPTCHA 340 to MGW 146, and MGW 146 may forward audio CAPTCHA 340to TS 142. TS 142 may provide audio CAPTCHA 340 to user device 110, anduser device 110 may play audio CAPTCHA 340 for a user of user device110. In one example, audio CAPTCHA 340 may request that the user enter,via a keypad or a touch screen of user device 110, the randomizedletters or numbers of audio CAPTCHA 340. Alternatively, audio CAPTCHA340 may request that the user audibly provide or repeat back, via userdevice 110, the randomized letters, numbers, phrases, etc. of audioCAPTCHA 340. A response 350 generated by the user may be provided fromuser device 110 to TS 142, and TS 142 may forward response 350 to MGW146. MGW 146 may forward response 350 to audio CAPTCHA component 310,and audio CAPTCHA component 310 may receive response 350.

Audio CAPTCHA component 310 may determine whether response 350 includesthe information requested by audio CAPTCHA 340. If response 350 includesthe information requested by audio CAPTCHA 340, VoIP call 320 may beforwarded to VoIP-based call center 160, as indicated by referencenumber 360. Once VoIP call 320 is received by VoIP-based call center160, user device 110 may be connected to VoIP-based call center 160, asindicated by reference number 370. However, if response 350 does notinclude the information requested by audio CAPTCHA 340, VoIP call 320may be dropped in order to prevent DoS attacks on VoIP-based call center160, as indicated by reference number 380. Alternatively, if response350 does not include the information requested by audio CAPTCHA 340,audio CAPTCHA component 310 may provide another audio CAPTCHA to userdevice 110. In one example, audio CAPTCHA component 310 may retrydifferent audio CAPTCHAs for a particular number of times (e.g., twotimes, three times, etc.) before dropping VoIP call 320.

Although FIG. 3 show example components of network portion 300, in otherimplementations, network portion 300 may include fewer components,different components, differently arranged components, or additionalcomponents than depicted in FIG. 3. Additionally, or alternatively, oneor more components of network portion 300 may perform one or more tasksdescribed as being performed by one or more other components of networkportion 300. For example, audio CAPTCHA component 310 may be provided inVoIP-based call center 160 instead of in SBC 148.

FIG. 4 is a diagram of example operations capable of being performed byanother example portion 400 of network 100 (FIG. 1). As shown in FIG. 4,network portion 400 may include user device 110, TS 142, MGW 146, SBC148, TDM-based call center 150, and audio CAPTCHA component 310. Userdevice 110, TS 142, MGW 146, SBC 148, TDM-based call center 150, andaudio CAPTCHA component 310 may include the features described above inconnection with, for example, one or more of FIGS. 1-3.

A user of user device 110 may generate a TDM call 410, and user device110 may provide TDM call 410 to TS 142. In one example, TDM call 410 mayinclude a voice call destined for TDM-based call center 150. TS 142 mayreceive TDM call 410, and may provide TDM call 410 to MGW 146. MGW 146may receive TDM call 410, and may provide TDM call 410 to audio CAPTCHAcomponent 310 of SBC 148.

Audio CAPTCHA component 310 may receive TDM call 410 and may receivecall volume information 420. Call volume information 420 may includeinformation indicating a volume or a number of calls currently beingreceived by TDM-based call center 150. In one example implementation,audio CAPTCHA component 310 may verify that a human is generating TDMcall 410 by generating an audio CAPTCHA 430 in response to VoIP call320. Audio CAPTCHA 430 may include the features described above inconnection with audio CAPTCHA 340.

Alternatively, audio CAPTCHA component 310 may determine whether TDMcall 410 is eligible for audio CAPTCHA 430 based on call volumeinformation 420. If call volume information 420 indicates that the callvolume at TDM-based call center 150 is greater than a particularthreshold (e.g., 70%, 80%, 90%, etc. of the capacity of TDM-based callcenter 150), audio CAPTCHA component 310 may determine that TDM call 410is eligible for audio CAPTCHA 430. If audio CAPTCHA component 310determines that TDM call 410 is not eligible for audio CAPTCHA 430,audio CAPTCHA component 310 may forward TDM call 410 to TDM-based callcenter 150, as indicated by reference number 450.

As further shown in FIG. 4, audio CAPTCHA component 310 may provideaudio CAPTCHA 430 to MGW 146, and MGW 146 may forward audio CAPTCHA 430to TS 142. TS 142 may provide audio CAPTCHA 430 to user device 110, anduser device 110 may play audio CAPTCHA 430 for a user of user device110. In one example, audio CAPTCHA 430 may request that the user enter,via user device 110, the randomized letters or numbers of audio CAPTCHA430. Alternatively, audio CAPTCHA 430 may request that the user audiblyprovide or repeat back, via user device 110, the randomized letters,numbers, phrases, etc. of audio CAPTCHA 430. A response 440 generated bythe user may be provided from user device 110 to TS 142, and TS 142 mayforward response 440 to MGW 146. MGW 146 may forward response 440 toaudio CAPTCHA component 310, and audio CAPTCHA component 310 may receiveresponse 440.

Audio CAPTCHA component 310 may determine whether response 440 includesthe information requested by audio CAPTCHA 430. If response 440 includesthe information requested by audio CAPTCHA 430, TDM call 410 may beforwarded to TDM-based call center 150, as indicated by reference number450. Once TDM call 410 is received by TDM-based call center 150, userdevice 110 may be connected to TDM-based call center 150, as indicatedby reference number 460. However, if response 440 does not include theinformation requested by audio CAPTCHA 430, TDM call 410 may be droppedin order to prevent DoS attacks on TDM-based call center 150, asindicated by reference number 470. Alternatively, if response 440 doesnot include the information requested by audio CAPTCHA 430, audioCAPTCHA component 310 may provide another audio CAPTCHA to user device110. In one example, audio CAPTCHA component 310 may retry differentaudio CAPTCHAs for a particular number of times (e.g., two times, threetimes, etc.) before dropping TDM call 410.

Although FIG. 4 show example components of network portion 400, in otherimplementations, network portion 400 may include fewer components,different components, differently arranged components, or additionalcomponents than depicted in FIG. 4. Additionally, or alternatively, oneor more components of network portion 400 may perform one or more tasksdescribed as being performed by one or more other components of networkportion 400. For example, audio CAPTCHA component 310 may be provided inTDM-based call center 150 instead of in SBC 148.

FIG. 5 is a diagram of example functional components of audio CAPTCHAcomponent 310. In one implementation, the functions described inconnection with FIG. 5 may be performed by one or more components ofdevice 200 (FIG. 2) or by one or more devices 200. As shown in FIG. 5,audio CAPTCHA component 310 may include a threshold determinationcomponent 500, a random information generation component 510, anoise/background mixer component 520, and a call forward/drop component530.

Threshold determination component 500 may receive VoIP call 320, callvolume information 330, TDM call 410, and/or call volume information420. In one example, threshold determination component 500 may determinewhether VoIP call 320 is eligible for audio CAPTCHA 340 based on callvolume information 330. If call volume information 330 indicates thatthe call volume at VoIP-based call center 160 is greater than aparticular threshold (e.g., 60%, 70%, 80%, etc. of the capacity ofVoIP-based call center 160), threshold determination component 500 maydetermine that VoIP call 320 is eligible for audio CAPTCHA 340, and mayprovide, to random information generation component 510, an indication540 that VoIP call 320 is eligible for audio CAPTCHA 340. If call volumeinformation 330 indicates that the call volume at VoIP-based call center160 is less than or equal to the particular threshold, thresholddetermination component 500 may provide, to call forward/drop component530, an indication 550 that VoIP call 320 is not eligible for audioCAPTCHA 340.

Alternatively, or additionally, threshold determination component 500may determine whether TDM call 410 is eligible for audio CAPTCHA 430based on call volume information 420. If call volume information 420indicates that the call volume at TDM-based call center 150 is greaterthan a particular threshold (e.g., 70%, 80%, 90%, etc. of the capacityof TDM-based call center 150), threshold determination component 500 maydetermine that TDM call 410 is eligible for audio CAPTCHA 430, and mayprovide, to random information generation component 510, indication 540that TDM call 410 is eligible for audio CAPTCHA 430. If call volumeinformation 420 indicates that the call volume at TDM-based call center150 is less than or equal to the particular threshold, thresholddetermination component 500 may provide, to call forward/drop component530, indication 550 that TDM call 410 is not eligible for audio CAPTCHA430.

Random information generation component 510 may receive indication 540from threshold determination component 500, and may generate randomaudio information 560 based on indication 540. Random audio information560 may include an audio file with randomly generated letters, numbers,phrases, etc. and a request to input or repeat (e.g., by a user of userdevice 110) the randomly generated letters, numbers, phrases, etc. Forexample, random audio information 560 may include an audio file thatstates “press 1, 4, and 6 followed by the star button,” where thenumbers “1, 4, and 6” may be randomly generated each time. As furthershown in FIG. 5, random information generation component 510 may providerandom audio information 560 to noise/background mixer component 520.

Noise/background mixer component 520 may receive random audioinformation 560 from random information generation component 510, andmay mix noise, background voices, or other sounds with random audioinformation 560. The mixture of the noise, background voices, or othersounds with random audio information 560 may produce audio CAPTCHA 340and/or audio CAPTCHA 430. Noise/background mixer component 520 mayprovide audio CAPTCHA 340/430 to user device 110 (not shown in FIG. 5)and to call forward/drop component 530.

Call forward/drop component 530 may receive indication 550 fromthreshold determination component 500, and may receive audio CAPTCHA340/430 from noise/background mixer component 520. If call forward/dropcomponent 530 receives indication 550, call forward/drop component 530may forward TDM call 320 to TDM-based call center 150 (not shown in FIG.5), as indicated by reference number 360. Alternatively, if callforward/drop component 530 receives indication 550, call forward/dropcomponent 530 may forward VoIP call 410 to VoIP-based call center 160(not shown in FIG. 5), as indicated by reference number 450.

As further shown in FIG. 5, call forward/drop component 530 may receiveresponse 350 and/or response 440 from user device 110 (not shown in FIG.5), and may determine whether response 350 or 440 includes theinformation requested by audio CAPTCHA 340 or 430, respectively. Ifresponse 350 includes the information requested by audio CAPTCHA 340,call forward/drop component 530 may forward VoIP call 320 VoIP-basedcall center 160 (not shown in FIG. 5), as indicated by reference number360. However, if response 350 does not include the information requestedby audio CAPTCHA 340, call forward/drop component 530 may drop VoIP call320, as indicated by reference number 380. If response 440 includes theinformation requested by audio CAPTCHA 430, call forward/drop component530 may forward TDM call 410 to TDM-based call center 150 (not shown inFIG. 5), as indicated by reference number 450. However, if response 440does not include the information requested by audio CAPTCHA 430, callforward/drop component 530 may drop TDM call 410, as indicated byreference number 470.

Although FIG. 5 shows example functional components of audio CAPTCHAcomponent 310, in other implementations, audio CAPTCHA component 310 mayinclude fewer functional components, different functional components,differently arranged functional components, or additional functionalcomponents than depicted in FIG. 5. Alternatively, or additionally, oneor more functional components of audio CAPTCHA component 310 may performone or more tasks described as being performed by one or more otherfunctional components of audio CAPTCHA component 310.

FIGS. 6 and 7 are flow charts of an example process 600 for mitigatingdenial of service attacks on call centers according to an implementationdescribed herein. In one implementation, process 600 may be performed byaudio CAPTCHA component 310 of SBC 148. Alternatively, or additionally,some or all of process 600 may be performed by another device or groupof devices, including or excluding audio CAPTCHA component 310 and/orSBC 148.

As shown in FIG. 6, process 600 may include receiving a call from a userdevice and call volume information (block 610), and determining whetherthe call is eligible for an audio CAPTCHA based on the call volumeinformation (block 620). For example, in an implementation describedabove in connection with FIG. 3, audio CAPTCHA component 310 of SBC 148may receive VoIP call 320 and may receive call volume information 330.Call volume information 330 may include information indicating a volumeor a number of calls currently being received by VoIP-based call center160. Audio CAPTCHA component 310 may determine whether VoIP call 320 iseligible for audio CAPTCHA 340 based on call volume information 330.

As further shown in FIG. 6, if the call is eligible for the audioCAPTCHA (block 620—ELIGIBLE), process 600 may include providing theaudio CAPTCHA to the user device (block 630) and receiving, from theuser device, a response to the audio CAPTCHA (block 640). For example,in an implementation described above in connection with FIG. 3, if callvolume information 330 indicates that the call volume at VoIP-based callcenter 160 is greater than a particular threshold (e.g., 60%, 70%, 80%,etc. of the capacity of VoIP-based call center 160), audio CAPTCHAcomponent 310 may determine that VoIP call 320 is eligible for audioCAPTCHA 340. Audio CAPTCHA component 310 may provide audio CAPTCHA 340to MGW 146, and MGW 146 may forward audio CAPTCHA 340 to TS 142. TS 142may provide audio CAPTCHA 340 to user device 110, and user device 110may play audio CAPTCHA 340 for a user of user device 110. Response 350generated by the user may be provided from user device 110 to TS 142,and TS 142 may forward response 350 to MGW 146. MGW 146 may forwardresponse 350 to audio CAPTCHA component 310, and audio CAPTCHA component310 may receive response 350.

Returning to FIG. 6, if the call is not eligible for the audio CAPTCHA(block 620—NOT ELIGIBLE), process 600 may include forwarding the call toa call center (block 660). For example, in an implementation describedabove in connection with FIG. 3, if audio CAPTCHA component 310determines that VoIP call 320 is not eligible for audio CAPTCHA 340,audio CAPTCHA component 310 may forward VoIP call 320 to VoIP-based callcenter 160, as indicated by reference number 360.

As further shown in FIG. 6, process 600 may include determining whetherthe response is correct (block 650). If the response is correct (block650—YES), process 600 may include forwarding the call to the call center(block 660). If the response is incorrect (block 650—NO), process 600may include dropping the call (block 670). For example, in animplementation described above in connection with FIG. 3, audio CAPTCHAcomponent 310 may determine whether response 350 includes theinformation requested by audio CAPTCHA 340. If response 350 includes theinformation requested by audio CAPTCHA 340, VoIP call 320 may beforwarded to VoIP-based call center 160, as indicated by referencenumber 360. However, if response 350 does not include the informationrequested by audio CAPTCHA 340, VoIP call 320 may be dropped, asindicated by reference number 380.

Process block 630 may include the process blocks depicted in FIG. 7. Asshown in FIG. 7, process block 630 may include generating random audioinformation for the audio CAPTCHA (block 700), mixing noise and/orbackground sound with the random audio information to create the audioCAPTCHA (block 710), and providing the created audio CAPTCHA to the userdevice (block 720). For example, in an implementation described above inconnection with FIG. 5, random information generation component 510 mayreceive indication 540 from threshold determination component 500, andmay generate random audio information 560 based on indication 540.Random audio information 560 may include an audio file with randomlygenerated letters, numbers, phrases, etc. and a request to input orrepeat (e.g., by a user of user device 110) the randomly generatedletters, numbers, phrases, etc. Random information generation component510 may provide random audio information 560 to noise/background mixercomponent 520. Noise/background mixer component 520 may receive randomaudio information 560 from random information generation component 510,and may mix noise, background voices, or other sounds with random audioinformation 560. The mixture of the noise, background voices, or othersounds with random audio information 560 may produce audio CAPTCHA340/430. Noise/background mixer component 520 may provide audio CAPTCHA340/430 to user device 110.

Systems and/or methods described herein may provide a mechanism toprevent DoS attacks on call centers when call volumes at the callcenters reach a particular threshold level. In one example, themechanism may include an audio CAPTCHA that prevents automated DoS callsfrom reaching call centers. The audio CAPTCHA may provide an audiorequest to a user of a user device placing a call to a call center, andthe user may provide an audio response to the audio request. If the userprovides an audio response that satisfies the audio request, the callmay be forwarded to the call center. However, if the audio response doesnot satisfy the audio request, the call may be dropped in order toprevent DoS attacks on the call center. The complexity of the audioCAPTCHA may be carefully balanced so as to have a high pass rate forhumans (e.g., users of user devices) and a low pass rate for devices(e.g., computers).

The foregoing description of implementations provides illustration anddescription, but is not intended to be exhaustive or to limit theimplementations to the precise form disclosed. Modifications andvariations are possible in light of the above disclosure or may beacquired from practice of the implementations.

For example, while series of blocks have been described with regard toFIGS. 6 and 7, the order of the blocks may be modified in otherimplementations. Further, non-dependent blocks may be performed inparallel.

It will be apparent that example aspects, as described above, may beimplemented in many different forms of software, firmware, and hardwarein the implementations illustrated in the figures. The actual softwarecode or specialized control hardware used to implement these aspectsshould not be construed as limiting. Thus, the operation and behavior ofthe aspects were described without reference to the specific softwarecode—it being understood that software and control hardware could bedesigned to implement the aspects based on the description herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the possible implementations. Infact, many of these features may be combined in ways not specificallyrecited in the claims and/or disclosed in the specification. Althougheach dependent claim listed below may directly depend on only one otherclaim, the disclosure of the possible implementations includes eachdependent claim in combination with every other claim in the claim set.

No element, act, or instruction used in the present application shouldbe construed as critical or essential to the possible implementationsunless explicitly described as such. Also, as used herein, the article“a” is intended to include one or more items. Where only one item isintended, the term “one” or similar language is used. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A method, comprising: receiving, by a device andfrom a user device, a call destined for a call center; receiving, by thedevice, call volume information associated with the call center;determining, by the device, whether the call is eligible for an audioCAPTCHA (Completely Automated Public Turing test to Tell Computer andHumans Apart) based on the call volume information; generating the audioCAPTCHA when the cell is eligible for the audio CAPTCHA; providing, bythe device, the audio CAPTCHA to the user device when the call iseligible for the audio CAPTCHA; receiving, by the device and from theuser device, a response to the audio CAPTCHA; determining, by thedevice, whether the response is correct; forwarding, by the device, thecall to the call center when the response is correct; and dropping, bythe device, the call when the response is incorrect.
 2. The method ofclaim 1, further comprising: forwarding the call to the call center whenthe call is not eligible for the audio CAPTCHA.
 3. The method of claim1, where the device includes a session border controller (SBC) device.4. The method of claim 1, where the call includes a voice over Internetprotocol (VoIP) call and the call center includes a VoIP-based callcenter.
 5. The method of claim 1, where the call includes atime-division multiplexing (TDM) call and the call center includes aTDM-based call center.
 6. The method of claim 1, further comprising:providing another audio CAPTCHA to the user device prior to dropping thecall; receiving, from the user device, another response to the otheraudio CAPTCHA; determining whether the other response is correct; andforwarding the call to the call center when the other response iscorrect.
 7. The method of claim 6, further comprising: dropping the callwhen the other response is incorrect.
 8. The method of claim 1, whereproviding the audio CAPTCHA to the user device further comprises:generating random audio information for the audio CAPTCHA; mixing noiseor background sound with the random audio information to create theaudio CAPTCHA; and providing the created audio CAPTCHA to the userdevice.
 9. A device, comprising: a processor to: receive, from a userdevice, a call destined for a call center, receive call volumeinformation associated with the call center, determine whether the callis eligible for an audio CAPTCHA (Completely Automated Public Turingtest to Tell Computer and Humans Apart) based on the call volumeinformation, forward the call to the call center when the call is noteligible for the audio CAPTCHA, provide the audio CAPTCHA to the userdevice when the call is eligible for the audio CAPTCHA, receive, fromthe user device, a response to the audio CAPTCHA, determine whether theresponse is correct, forward the call to the call center when theresponse is correct, and drop the call when the response is incorrect.10. The device of claim 9, where the call includes a voice over Internetprotocol (VoIP) call and the call center includes a VoIP-based callcenter.
 11. The device of claim 9, where the call includes a non-voiceover Internet protocol (VoIP) call and the call center includes a nonVoIP-based call center.
 12. The device of claim 9, where the processoris further to: provide another audio CAPTCHA to the user device prior todropping the call, receive, from the user device, another response tothe other audio CAPTCHA, determine whether the other response iscorrect, and forward the call to the call center when the other responseis correct.
 13. The device of claim 12, where the processor is furtherto: drop the call when the other response is incorrect.
 14. The deviceof claim 9, where, when providing the audio CAPTCHA to the user device,the processor is further to: generate random audio information for theaudio CAPTCHA, mix noise or background sound with the random audioinformation to create the audio CAPTCHA, and provide the created audioCAPTCHA to the user device.
 15. A computer-readable medium, comprising:one or more instructions that, when executed by a processor of a device,cause the processor to: receive, from a user device, a call destined fora call center, provide an audio CAPTCHA (Completely Automated PublicTuring test to Tell Computer and Humans Apart) to the user device inresponse to the call, receive, from the user device, a response to theaudio CAPTCHA, determine whether the response is correct, forward thecall to the call center when the response is correct, and drop the callwhen the response is incorrect.
 16. The computer-readable medium ofclaim 15, where the call includes a voice over Internet protocol (VoIP)call and the call center includes a VoIP-based call center.
 17. Thecomputer-readable medium of claim 15, where the call includes atime-division multiplexing (TDM) call and the call center includes aTDM-based call center.
 18. The computer-readable medium of claim 15,further comprising: one or more instructions that, when executed by theprocessor of the device, cause the processor to: provide another audioCAPTCHA to the user device prior to dropping the call, receive, from theuser device, another response to the other audio CAPTCHA, determinewhether the other response is correct, and forward the call to the callcenter when the other response is correct.
 19. The computer-readablemedium of claim 18, further comprising: one or more instructions that,when executed by the processor of the device, cause the processor to:drop the call when the other response is incorrect.
 20. Thecomputer-readable medium of claim 15, where the audio CAPTCHA includesrandomly generated audio information mixed with noise or backgroundsound.